Antoine Beaupr : My free software activities, February and March 2017
Looking into self-financing
Before I begin, I should mention that I started tracking my time
working on free software more systematically. I spend a lot of time on
the computer, as regular readers of this blog might
remember so I wanted to know exactly how
much time was paid vs free work. I was already using org-mode's
time clock system to keep track of my work hours, so I just
extended this to my regular free software contributions, which also
helps in writing those reports.
It turns out that over 60% of my computer time is spent working on
free software. That's huge! I was expecting something more along the
range of 20 to 40% of my time. So I started thinking about ways of
financing this work. I created a Patreon page but I'm hesitant
into launching such a campaign: the only thing worse than "no patreon
page" is "a patreon page with failed goals and no one financing
it". So before starting such an effort, I'd like to get a feeling of
what other people's experience with it are. I know that joeyh is
close to achieving his goals, but I can't compare with the guy that
invented git-annex or debhelper, so I'm concerned I wouldn't be able
to raise the same level of funding.
So any advice you have, feel free to contact me in private or in the
comments. If you would be ready to fund my work, I'd love to know
about it, obviously, but I guess I wouldn't get real numbers until I
actually open up such a page...
Now, onto the regular report.
Wallabako
I spent a good chunk of time completing most of the things I had in
mind for Wallabako, which I mentioned quickly in the previous
report. Wallabako
is now much easier to installed, with clearer instructions, an easier
to use configuration file, more reliable synchronization and read
status propagation. As usual the Wallabako README file has all the
details.
I've also looked at better integration with Koreader, the free
software e-reader that forms the basis of
the okreader free software distribution which has been able to
port Debian to the Kobo e-readers, a project I am really excited
about. This project has the potential of supporting Kobo readers
beyond the lifetime that upstream grants it and removes a lot of
proprietary software and spyware that ships with the Kobo readers. So
I have made a few contributions to okreader
and also on koreader, the ebook reader okreader is based on.
Stressant
I rewrote stressant, my simple burn-in and
stress-testing tool. After struggling in turn
with Debirf, live-build, vmdebootstrap and even FAI, I
just figured maybe it wasn't the best idea to try and reinvent that
particular wheel: instead of reinventing how to build yet
another Debian system build tool, maybe I should just reuse what's
already there.
It turns out there's a well known, succesful and fairly complete
recovery system called Grml. It is a Debian Derivative, so all
I needed to do was to stop procrastinating and actually write the
actual stressant tool instead of just creating a distribution with a
bunch of random tools shipped in. This allowed me to focus on which
tools were the best to stress test different components. This
selection ended up being:
- lshw and smartmon-tools (
smartctl) for
hardware inventory
- coreutils's famous
dd, hdparm, fio and (again) smartctl) for disk testing
- stress-ng for CPU testing
- iperf3 for network testing
fio can also be used to overwrite disk drives with the proper
options (--overwrite and --size=100%), although grml also ships
with nwipe for wiping old spinning disks and hdparm to
do a secure erase of SSD disks (whatever that's worth).
Stressant still needs to be shipped with grml for this transition
to be complete. In the meantime, I was able to configure the excellent
public Gitlab CI service to provide ISO images with Stressant
built-in as a stopgap measure. I also need to figure out a way to
automate starting stressant from a boot menu to automate deployments
on a larger scale, although because I have little need for the feature
at this moment in time, this will likely wait for a sponsor to show up
for this to be implemented.
Still, stressant has useful features like the capability of sending
logs by email using a fresh new implementation of the
Python SMTPHandler (BufferedSMTPHandler) which waits for
logging to complete before sending a single email. Another interesting
piece of code in there is the NegateAction argparse handler
that enables the use of "toggle flags" (e.g. --flag /
--no-flag). I'm so happy with the code that I figure I could just
share it here directly:
class NegateAction(argparse.Action):
'''add a toggle flag to argparse
this is similar to 'store_true' or 'store_false', but allows
arguments prefixed with --no to disable the default. the default
is set depending on the first argument - if it starts with the
negative form (define by default as '--no'), the default is False,
otherwise True.
'''
negative = '--no'
def __init__(self, option_strings, *args, **kwargs):
'''set default depending on the first argument'''
default = not option_strings[0].startswith(self.negative)
super(NegateAction, self).__init__(option_strings, *args,
default=default, nargs=0, **kwargs)
def __call__(self, parser, ns, values, option):
'''set the truth value depending on whether
it starts with the negative form'''
setattr(ns, self.dest, not option.startswith(self.negative))
Short and sweet. I wonder why stuff like this is not in the standard
library yet - maybe just because no one bothered yet? It'd be great to
get feedback of more experienced Pythonistas on this one.
I hope that my work on Stressant is complete. I get zero funding for
this work, and have little use for it myself: I manage only a few
machines and such a tool really shines when you regularly put new
hardware online, which is (fortunately?) not my case anymore. I'd be
happy, of course, to accompany organisations and people that wish to
further develop and use such a tool.
A short demo of stressant as well as detailed description of how
it works is of course available in its README file.
Standard third party repositories
After looking
at improvements for the grml repository instructions, I realized
there was no real "best practices" document on how to configure an Apt
repository. Sure, there are tools like reprepro and
others, but those hardly qualify as policy: they are very flexible and
there are lots of ways to create insecure repositories
or curl sh style instructions, which we of course generally want
to avoid.
While the larger problem of Unstrusted Debian packages remain
generally unsolved (e.g. when you install any .deb file, it can
get root on your system), it seemed to me one critical part of this
problem was how to add a random third-party repository to your machine
while limiting, as much as possible, what possible attackers could
do with such a repository. In other words, to solve the more general
problem of insecure .deb files, we also need to solve the
distribution problem, otherwise fixing the .deb files themselves
will be useless.
This lead to the creation of standardized repository instructions
that define:
- how to distribute the repository's public signing key (ie. over
HTTPS)
- how to name suites and components (e.g. use
stable and main
unless you have a good reason, and explain yourself)
- recommend a healthy does of apt preferences pinning
- how to distribute keys (e.g. with a
derive-archive-keyring
package)
I've seen so many third party repositories get this wrong. For
example, a lot of repositories recommend this type of command to
intialize the OpenPGP trust path:
curl http://example.com/key.asc apt-key add -
This has the following problems:
- the key is transfered in plaintext and can easily be manipulated by
an active attacker (e.g. a router on your path to the server or a
neighbor in a Wifi cafe)
- the key is added to the main trust root, which allows the key to
authentify as the real Debian archive, therefore giving it all
rights over all packages
- since it's part of the global archive, it's difficult for a package
to remove/add the key when a key rollover is necessary (and
repositories generally don't provide a
deriv-archive-keyring to
do that process anyways)
An example of this are the Docker install instructions that, at
least, manage to do this over HTTPS. Some other repositories don't
even bother teaching people about the proper way of adding
those keys. We settled for:
wget -O /usr/share/keyrings/deriv-archive-keyring.gpg https://deriv.example.net/debian/deriv-archive-keyring.gpg
That location was explicitly chosen to be out of the main trust
directory, so that it needs to be explicitly added to the sources.list
as well:
deb [signed-by=/usr/share/keyrings/deriv-archive-keyring.gpg] https://deriv.example.net/debian/ stable main
Similarly, we highly recommend users setup "apt pinning" to restrict
what a given repository can do. Since pinning is so confusing, most
people don't actually bother even configuring it and I have yet to see
a single repo advise its users to configure those preferences, which
are essential to limit what a repository can do. To keep configuration
simple, we recommend this:
Package: *
Pin: origin deriv.example.net
Pin-Priority: 100
Obviously, for a single-package repository, the actual package name
should be listed, e.g.:
Package: foo
Pin: origin deriv.example.net
Pin-Priority: 100
And the priority should probably be set to 1 unless you want to
allow automatic upgrades.
It is my hope that this design will get more traction in the years to
come and become a de-facto standard that will be a key part in safely
adding third party repositories. There is obviously much more work to
be done to improve security when installing untrusted .deb files,
and I encourage Debian developers to consider contributing to the
UntrustedDebs discussions and particularly to the
Teams/Dpkg/Spec/DeclarativePackaging work.
Signal R&D
I spent a significant amount of time this month struggling with
the Signal project on my phone. I'm still ambivalent on Signal:
it's a centralized designed, too dependent on phone numbers, but I
must admit they get a lot of things right and it's the only
free-software platform that allows for easy-to-use, multi-platform
videoconferencing that my family can use.
I've been following Signal for a while: up until now, I had been using
the LibreSignal rebuild of the official client, as it is
distributed on a F-Droid repository. Because I try to avoid Google
(proprietary) software on my phone, it's basically the only way I
could even install Signal. Unfortunately, the repository is out of
date and introduces another point of trust in the distribution
model: now you not only need to trust the Signal authors to do the
right thing, you also need to trust that F-Droid repo not to inject
nasty code on your phone. I've therefore started a discussion
about how Signal could be distributed outside of the Google Play
Store. I'd like to think it's one of the things that led the Signal
people to distribute an official copy of Signal outside of the
playstore.
After much struggling, I was able to upgrade to this official client
and will be able to upgrade easily by just downloading the APK. (Do
note that I ended up reinstalling and re-registering Signal, which
unfortunately changed my secret keys.)
I do hope Signal enters F-Droid one day, but it could take a while
because it still doesn't work without Google services
and barely works with MicroG, the free software alternative to
the Google services clients. Moxie also set a list of requirements
like crash reporting and statistics that need to be implemented on
F-Droid's side before he agrees to the deployment, so this could take
a while.
I've also participated in the, ahem, discussion on the JWZ blog
regarding a supposed vulnerability in Signal where it would leak
previously unknown phone numbers to third parties. I reviewed the
way the phone number is uploaded and, while it's possible to create a
rainbow table of phone numbers (which are hashed with a truncated
SHA-1 checksum), I couldn't verify the claims of other participants in
the thread. For me, Signal still does the right thing with contacts,
although I do question the way "read status" notifications get
transmitted, but that belong in another bug report / blog post.
Debian Long Term Support (LTS)
It's been more than a year working on Debian LTS, started by
Raphael Hertzog at Freexian. I didn't work much in February so I
had a lot of hours to catchup with, and was unfortunately unable to do
so, partly because I was busy with other projects, and partly because
my colleagues are doing a great job at resolving the most important
issues.
So one my concerns this month was finding work. It seemed that all the
hard packages were either taken (e.g. my usual favorites, tiff and
imagemagick, we done by others) or just too challenging (e.g. I don't
feel quite comfortable tackling the LTS branch of the Linux kernel
yet).
I spent quite a bit of time trying to figure out what was wrong with
pcre3, only to realise the "32" in the report was not about the
architecture, but about the character width. Because of thise, I
marked 4 CVEs (CVE-2017-7186, CVE-2017-7244, CVE-2017-7245, CVE-2017-7246) as "not-affected", since the
32-bith character support wasn't enabled in wheezy (or jessie, for
that matter). I still spent some time trying to reproduce the issues,
which require a compiler with an AddressSanitizer, something that
was introduced in both Clang and GCC after Wheezy was released, which
makes reproducing this fairly complicated...
This allowed me to experiment more with Vagrant, however, and I have
provided the Debian cloud team with a 32-bit Vagrant box that was
merged in shortly after, although it doesn't show up yet in
the official list of Debian images.
Then I looked at the apparmor situation (CVE-2017-6507),
Debian bug #858768). That was one tricky bug as well, since it's not a
security issue in apparmor per se, but more an issue with things that
assume a certain behavior from apparmor. I have concluded that Wheezy
was not affected because there are no assumptions of proper isolation
there - which are provided only starting from LXC 1.0 - and Docker is
not in Wheezy. I also couldn't reproduce the issue on Jessie, but, as
it turns out, the issue was sysvinit-specific, which is why I couldn't
reproduce it under the default systemd configuration shipped with
Jessie.
I also looked at the various binutils security issues: as I reported on the mailing list, I didn't see anything serious
enough in there to warrant a a security release and followed the lead
of both the stable and Red Hat security teams by marking this
"no-dsa". I similiarly reviewed the mp3splt security issues (specifically CVE-2017-5666) and was fairly puzzled by that issue, which seems
to be triggered only the same address sanitization extensions than PCRE, although there was
some pretty wild interplay with debugging flags in there. All in all,
it seems we can't reproduce that issue in wheezy, but I do not feel
confident enough in the results to push that issue aside for now.
I finally uploaded the pending graphicsmagick issue (DLA-547-2), a regression
update to fix a crash that was introduced in the previous release
(DLA-547-1, mistakenly named DLA-574-1). Hopefully that release should clear up some of the
confusion and fix the regression.
I also released DLA-879-1 for the CVE-2017-6369 in
firebird2.5 which was an interesting experiment:
I couldn't reproduce the issue in a local VM. After following
the Ubuntu setup tutorial, as I wasn't too familiar with the
Firebird database until now (hint: the default username and password
is sysdba/masterkey), I ended up assuming we were vulnerable and
just backporting the patch after seeing the jessie folks push out a
release just in case.
I also looked at updating the ca-certificates package to
deal with the pending WoSign/Startcom
removal: I made an explicit list of the CAs that need to be removed
after reviewing the Mozilla list. I also sent a patch for an unrelated
issue where ca-certificates is writing to /usr/local (!!) in Debian bug #843722.
I have also done some "meta" work in starting a discussion about fixing the
missing DLA links in the tracker, as you will notice all of the
above links lead to nowhere. Thanks to pabs, there are now some
links but unfortunately there are about 500
DLAs missing from the website. We also discussed ways to Debian bug #859123,
something which is currently a manual process. This is now in the
hands of the excellent webmaster
team.
I have also filed a few missing security bugs (Debian bug #859135,
Debian bug #859136), partly because I wanted to help the security
team. But it turned out that I felt the script needed some
improvements, so I submitted a patch to improve the script so it is easier to
run.
Other projects
As usual, there's the usual mixed bags of chaos:
- converted the Charybdis IRC operator guide from SGML (yuck) to RST (PR)
- patches and discussions on
the
restic backup software review and
backup data generation program in
the hope of reducing duplication with the other two similar
projects (Obnam's genbackupdata and
Borg's
backupdata)
- atheme-services
security upload (still
need to do the same with charybdis
- neat cleanup of
the Python Cryptography
table of contents
(PR)
- basic maintenance on
the Linkchecker
project, including particularly a set
of
community guidelines which
I'd like to standardize as well
- raised a red flag on the security of the Weechat project by
reporting that most users are not aware that Weechat relays provide
arbitrary remote code execution to clients, upstream thinks users
are to blame, issue still opened
- git-annex
documentation:
semi-synchronized remotes and antipatterns
- tried to unblock the mess that TLS verification still is in Emacs
(Debian bug #816063)
More stuff on Github...
Stressant
I rewrote stressant, my simple burn-in and
stress-testing tool. After struggling in turn
with Debirf, live-build, vmdebootstrap and even FAI, I
just figured maybe it wasn't the best idea to try and reinvent that
particular wheel: instead of reinventing how to build yet
another Debian system build tool, maybe I should just reuse what's
already there.
It turns out there's a well known, succesful and fairly complete
recovery system called Grml. It is a Debian Derivative, so all
I needed to do was to stop procrastinating and actually write the
actual stressant tool instead of just creating a distribution with a
bunch of random tools shipped in. This allowed me to focus on which
tools were the best to stress test different components. This
selection ended up being:
- lshw and smartmon-tools (
smartctl) for
hardware inventory
- coreutils's famous
dd, hdparm, fio and (again) smartctl) for disk testing
- stress-ng for CPU testing
- iperf3 for network testing
fio can also be used to overwrite disk drives with the proper
options (--overwrite and --size=100%), although grml also ships
with nwipe for wiping old spinning disks and hdparm to
do a secure erase of SSD disks (whatever that's worth).
Stressant still needs to be shipped with grml for this transition
to be complete. In the meantime, I was able to configure the excellent
public Gitlab CI service to provide ISO images with Stressant
built-in as a stopgap measure. I also need to figure out a way to
automate starting stressant from a boot menu to automate deployments
on a larger scale, although because I have little need for the feature
at this moment in time, this will likely wait for a sponsor to show up
for this to be implemented.
Still, stressant has useful features like the capability of sending
logs by email using a fresh new implementation of the
Python SMTPHandler (BufferedSMTPHandler) which waits for
logging to complete before sending a single email. Another interesting
piece of code in there is the NegateAction argparse handler
that enables the use of "toggle flags" (e.g. --flag /
--no-flag). I'm so happy with the code that I figure I could just
share it here directly:
class NegateAction(argparse.Action):
'''add a toggle flag to argparse
this is similar to 'store_true' or 'store_false', but allows
arguments prefixed with --no to disable the default. the default
is set depending on the first argument - if it starts with the
negative form (define by default as '--no'), the default is False,
otherwise True.
'''
negative = '--no'
def __init__(self, option_strings, *args, **kwargs):
'''set default depending on the first argument'''
default = not option_strings[0].startswith(self.negative)
super(NegateAction, self).__init__(option_strings, *args,
default=default, nargs=0, **kwargs)
def __call__(self, parser, ns, values, option):
'''set the truth value depending on whether
it starts with the negative form'''
setattr(ns, self.dest, not option.startswith(self.negative))
Short and sweet. I wonder why stuff like this is not in the standard
library yet - maybe just because no one bothered yet? It'd be great to
get feedback of more experienced Pythonistas on this one.
I hope that my work on Stressant is complete. I get zero funding for
this work, and have little use for it myself: I manage only a few
machines and such a tool really shines when you regularly put new
hardware online, which is (fortunately?) not my case anymore. I'd be
happy, of course, to accompany organisations and people that wish to
further develop and use such a tool.
A short demo of stressant as well as detailed description of how
it works is of course available in its README file.
Standard third party repositories
After looking
at improvements for the grml repository instructions, I realized
there was no real "best practices" document on how to configure an Apt
repository. Sure, there are tools like reprepro and
others, but those hardly qualify as policy: they are very flexible and
there are lots of ways to create insecure repositories
or curl sh style instructions, which we of course generally want
to avoid.
While the larger problem of Unstrusted Debian packages remain
generally unsolved (e.g. when you install any .deb file, it can
get root on your system), it seemed to me one critical part of this
problem was how to add a random third-party repository to your machine
while limiting, as much as possible, what possible attackers could
do with such a repository. In other words, to solve the more general
problem of insecure .deb files, we also need to solve the
distribution problem, otherwise fixing the .deb files themselves
will be useless.
This lead to the creation of standardized repository instructions
that define:
- how to distribute the repository's public signing key (ie. over
HTTPS)
- how to name suites and components (e.g. use
stable and main
unless you have a good reason, and explain yourself)
- recommend a healthy does of apt preferences pinning
- how to distribute keys (e.g. with a
derive-archive-keyring
package)
I've seen so many third party repositories get this wrong. For
example, a lot of repositories recommend this type of command to
intialize the OpenPGP trust path:
curl http://example.com/key.asc apt-key add -
This has the following problems:
- the key is transfered in plaintext and can easily be manipulated by
an active attacker (e.g. a router on your path to the server or a
neighbor in a Wifi cafe)
- the key is added to the main trust root, which allows the key to
authentify as the real Debian archive, therefore giving it all
rights over all packages
- since it's part of the global archive, it's difficult for a package
to remove/add the key when a key rollover is necessary (and
repositories generally don't provide a
deriv-archive-keyring to
do that process anyways)
An example of this are the Docker install instructions that, at
least, manage to do this over HTTPS. Some other repositories don't
even bother teaching people about the proper way of adding
those keys. We settled for:
wget -O /usr/share/keyrings/deriv-archive-keyring.gpg https://deriv.example.net/debian/deriv-archive-keyring.gpg
That location was explicitly chosen to be out of the main trust
directory, so that it needs to be explicitly added to the sources.list
as well:
deb [signed-by=/usr/share/keyrings/deriv-archive-keyring.gpg] https://deriv.example.net/debian/ stable main
Similarly, we highly recommend users setup "apt pinning" to restrict
what a given repository can do. Since pinning is so confusing, most
people don't actually bother even configuring it and I have yet to see
a single repo advise its users to configure those preferences, which
are essential to limit what a repository can do. To keep configuration
simple, we recommend this:
Package: *
Pin: origin deriv.example.net
Pin-Priority: 100
Obviously, for a single-package repository, the actual package name
should be listed, e.g.:
Package: foo
Pin: origin deriv.example.net
Pin-Priority: 100
And the priority should probably be set to 1 unless you want to
allow automatic upgrades.
It is my hope that this design will get more traction in the years to
come and become a de-facto standard that will be a key part in safely
adding third party repositories. There is obviously much more work to
be done to improve security when installing untrusted .deb files,
and I encourage Debian developers to consider contributing to the
UntrustedDebs discussions and particularly to the
Teams/Dpkg/Spec/DeclarativePackaging work.
Signal R&D
I spent a significant amount of time this month struggling with
the Signal project on my phone. I'm still ambivalent on Signal:
it's a centralized designed, too dependent on phone numbers, but I
must admit they get a lot of things right and it's the only
free-software platform that allows for easy-to-use, multi-platform
videoconferencing that my family can use.
I've been following Signal for a while: up until now, I had been using
the LibreSignal rebuild of the official client, as it is
distributed on a F-Droid repository. Because I try to avoid Google
(proprietary) software on my phone, it's basically the only way I
could even install Signal. Unfortunately, the repository is out of
date and introduces another point of trust in the distribution
model: now you not only need to trust the Signal authors to do the
right thing, you also need to trust that F-Droid repo not to inject
nasty code on your phone. I've therefore started a discussion
about how Signal could be distributed outside of the Google Play
Store. I'd like to think it's one of the things that led the Signal
people to distribute an official copy of Signal outside of the
playstore.
After much struggling, I was able to upgrade to this official client
and will be able to upgrade easily by just downloading the APK. (Do
note that I ended up reinstalling and re-registering Signal, which
unfortunately changed my secret keys.)
I do hope Signal enters F-Droid one day, but it could take a while
because it still doesn't work without Google services
and barely works with MicroG, the free software alternative to
the Google services clients. Moxie also set a list of requirements
like crash reporting and statistics that need to be implemented on
F-Droid's side before he agrees to the deployment, so this could take
a while.
I've also participated in the, ahem, discussion on the JWZ blog
regarding a supposed vulnerability in Signal where it would leak
previously unknown phone numbers to third parties. I reviewed the
way the phone number is uploaded and, while it's possible to create a
rainbow table of phone numbers (which are hashed with a truncated
SHA-1 checksum), I couldn't verify the claims of other participants in
the thread. For me, Signal still does the right thing with contacts,
although I do question the way "read status" notifications get
transmitted, but that belong in another bug report / blog post.
Debian Long Term Support (LTS)
It's been more than a year working on Debian LTS, started by
Raphael Hertzog at Freexian. I didn't work much in February so I
had a lot of hours to catchup with, and was unfortunately unable to do
so, partly because I was busy with other projects, and partly because
my colleagues are doing a great job at resolving the most important
issues.
So one my concerns this month was finding work. It seemed that all the
hard packages were either taken (e.g. my usual favorites, tiff and
imagemagick, we done by others) or just too challenging (e.g. I don't
feel quite comfortable tackling the LTS branch of the Linux kernel
yet).
I spent quite a bit of time trying to figure out what was wrong with
pcre3, only to realise the "32" in the report was not about the
architecture, but about the character width. Because of thise, I
marked 4 CVEs (CVE-2017-7186, CVE-2017-7244, CVE-2017-7245, CVE-2017-7246) as "not-affected", since the
32-bith character support wasn't enabled in wheezy (or jessie, for
that matter). I still spent some time trying to reproduce the issues,
which require a compiler with an AddressSanitizer, something that
was introduced in both Clang and GCC after Wheezy was released, which
makes reproducing this fairly complicated...
This allowed me to experiment more with Vagrant, however, and I have
provided the Debian cloud team with a 32-bit Vagrant box that was
merged in shortly after, although it doesn't show up yet in
the official list of Debian images.
Then I looked at the apparmor situation (CVE-2017-6507),
Debian bug #858768). That was one tricky bug as well, since it's not a
security issue in apparmor per se, but more an issue with things that
assume a certain behavior from apparmor. I have concluded that Wheezy
was not affected because there are no assumptions of proper isolation
there - which are provided only starting from LXC 1.0 - and Docker is
not in Wheezy. I also couldn't reproduce the issue on Jessie, but, as
it turns out, the issue was sysvinit-specific, which is why I couldn't
reproduce it under the default systemd configuration shipped with
Jessie.
I also looked at the various binutils security issues: as I reported on the mailing list, I didn't see anything serious
enough in there to warrant a a security release and followed the lead
of both the stable and Red Hat security teams by marking this
"no-dsa". I similiarly reviewed the mp3splt security issues (specifically CVE-2017-5666) and was fairly puzzled by that issue, which seems
to be triggered only the same address sanitization extensions than PCRE, although there was
some pretty wild interplay with debugging flags in there. All in all,
it seems we can't reproduce that issue in wheezy, but I do not feel
confident enough in the results to push that issue aside for now.
I finally uploaded the pending graphicsmagick issue (DLA-547-2), a regression
update to fix a crash that was introduced in the previous release
(DLA-547-1, mistakenly named DLA-574-1). Hopefully that release should clear up some of the
confusion and fix the regression.
I also released DLA-879-1 for the CVE-2017-6369 in
firebird2.5 which was an interesting experiment:
I couldn't reproduce the issue in a local VM. After following
the Ubuntu setup tutorial, as I wasn't too familiar with the
Firebird database until now (hint: the default username and password
is sysdba/masterkey), I ended up assuming we were vulnerable and
just backporting the patch after seeing the jessie folks push out a
release just in case.
I also looked at updating the ca-certificates package to
deal with the pending WoSign/Startcom
removal: I made an explicit list of the CAs that need to be removed
after reviewing the Mozilla list. I also sent a patch for an unrelated
issue where ca-certificates is writing to /usr/local (!!) in Debian bug #843722.
I have also done some "meta" work in starting a discussion about fixing the
missing DLA links in the tracker, as you will notice all of the
above links lead to nowhere. Thanks to pabs, there are now some
links but unfortunately there are about 500
DLAs missing from the website. We also discussed ways to Debian bug #859123,
something which is currently a manual process. This is now in the
hands of the excellent webmaster
team.
I have also filed a few missing security bugs (Debian bug #859135,
Debian bug #859136), partly because I wanted to help the security
team. But it turned out that I felt the script needed some
improvements, so I submitted a patch to improve the script so it is easier to
run.
Other projects
As usual, there's the usual mixed bags of chaos:
- converted the Charybdis IRC operator guide from SGML (yuck) to RST (PR)
- patches and discussions on
the
restic backup software review and
backup data generation program in
the hope of reducing duplication with the other two similar
projects (Obnam's genbackupdata and
Borg's
backupdata)
- atheme-services
security upload (still
need to do the same with charybdis
- neat cleanup of
the Python Cryptography
table of contents
(PR)
- basic maintenance on
the Linkchecker
project, including particularly a set
of
community guidelines which
I'd like to standardize as well
- raised a red flag on the security of the Weechat project by
reporting that most users are not aware that Weechat relays provide
arbitrary remote code execution to clients, upstream thinks users
are to blame, issue still opened
- git-annex
documentation:
semi-synchronized remotes and antipatterns
- tried to unblock the mess that TLS verification still is in Emacs
(Debian bug #816063)
More stuff on Github...
smartctl) for
hardware inventorydd, hdparm, fio and (again) smartctl) for disk testingclass NegateAction(argparse.Action):
'''add a toggle flag to argparse
this is similar to 'store_true' or 'store_false', but allows
arguments prefixed with --no to disable the default. the default
is set depending on the first argument - if it starts with the
negative form (define by default as '--no'), the default is False,
otherwise True.
'''
negative = '--no'
def __init__(self, option_strings, *args, **kwargs):
'''set default depending on the first argument'''
default = not option_strings[0].startswith(self.negative)
super(NegateAction, self).__init__(option_strings, *args,
default=default, nargs=0, **kwargs)
def __call__(self, parser, ns, values, option):
'''set the truth value depending on whether
it starts with the negative form'''
setattr(ns, self.dest, not option.startswith(self.negative))
.deb file, it can
get root on your system), it seemed to me one critical part of this
problem was how to add a random third-party repository to your machine
while limiting, as much as possible, what possible attackers could
do with such a repository. In other words, to solve the more general
problem of insecure .deb files, we also need to solve the
distribution problem, otherwise fixing the .deb files themselves
will be useless.
This lead to the creation of standardized repository instructions
that define:
- how to distribute the repository's public signing key (ie. over HTTPS)
- how to name suites and components (e.g. use
stableandmainunless you have a good reason, and explain yourself) - recommend a healthy does of apt preferences pinning
- how to distribute keys (e.g. with a
derive-archive-keyringpackage)
curl http://example.com/key.asc apt-key add -
- the key is transfered in plaintext and can easily be manipulated by an active attacker (e.g. a router on your path to the server or a neighbor in a Wifi cafe)
- the key is added to the main trust root, which allows the key to authentify as the real Debian archive, therefore giving it all rights over all packages
- since it's part of the global archive, it's difficult for a package
to remove/add the key when a key rollover is necessary (and
repositories generally don't provide a
deriv-archive-keyringto do that process anyways)
wget -O /usr/share/keyrings/deriv-archive-keyring.gpg https://deriv.example.net/debian/deriv-archive-keyring.gpg
deb [signed-by=/usr/share/keyrings/deriv-archive-keyring.gpg] https://deriv.example.net/debian/ stable main
Package: *
Pin: origin deriv.example.net
Pin-Priority: 100
Package: foo
Pin: origin deriv.example.net
Pin-Priority: 100
1 unless you want to
allow automatic upgrades.
It is my hope that this design will get more traction in the years to
come and become a de-facto standard that will be a key part in safely
adding third party repositories. There is obviously much more work to
be done to improve security when installing untrusted .deb files,
and I encourage Debian developers to consider contributing to the
UntrustedDebs discussions and particularly to the
Teams/Dpkg/Spec/DeclarativePackaging work.
Signal R&D
I spent a significant amount of time this month struggling with
the Signal project on my phone. I'm still ambivalent on Signal:
it's a centralized designed, too dependent on phone numbers, but I
must admit they get a lot of things right and it's the only
free-software platform that allows for easy-to-use, multi-platform
videoconferencing that my family can use.
I've been following Signal for a while: up until now, I had been using
the LibreSignal rebuild of the official client, as it is
distributed on a F-Droid repository. Because I try to avoid Google
(proprietary) software on my phone, it's basically the only way I
could even install Signal. Unfortunately, the repository is out of
date and introduces another point of trust in the distribution
model: now you not only need to trust the Signal authors to do the
right thing, you also need to trust that F-Droid repo not to inject
nasty code on your phone. I've therefore started a discussion
about how Signal could be distributed outside of the Google Play
Store. I'd like to think it's one of the things that led the Signal
people to distribute an official copy of Signal outside of the
playstore.
After much struggling, I was able to upgrade to this official client
and will be able to upgrade easily by just downloading the APK. (Do
note that I ended up reinstalling and re-registering Signal, which
unfortunately changed my secret keys.)
I do hope Signal enters F-Droid one day, but it could take a while
because it still doesn't work without Google services
and barely works with MicroG, the free software alternative to
the Google services clients. Moxie also set a list of requirements
like crash reporting and statistics that need to be implemented on
F-Droid's side before he agrees to the deployment, so this could take
a while.
I've also participated in the, ahem, discussion on the JWZ blog
regarding a supposed vulnerability in Signal where it would leak
previously unknown phone numbers to third parties. I reviewed the
way the phone number is uploaded and, while it's possible to create a
rainbow table of phone numbers (which are hashed with a truncated
SHA-1 checksum), I couldn't verify the claims of other participants in
the thread. For me, Signal still does the right thing with contacts,
although I do question the way "read status" notifications get
transmitted, but that belong in another bug report / blog post.
Debian Long Term Support (LTS)
It's been more than a year working on Debian LTS, started by
Raphael Hertzog at Freexian. I didn't work much in February so I
had a lot of hours to catchup with, and was unfortunately unable to do
so, partly because I was busy with other projects, and partly because
my colleagues are doing a great job at resolving the most important
issues.
So one my concerns this month was finding work. It seemed that all the
hard packages were either taken (e.g. my usual favorites, tiff and
imagemagick, we done by others) or just too challenging (e.g. I don't
feel quite comfortable tackling the LTS branch of the Linux kernel
yet).
I spent quite a bit of time trying to figure out what was wrong with
pcre3, only to realise the "32" in the report was not about the
architecture, but about the character width. Because of thise, I
marked 4 CVEs (CVE-2017-7186, CVE-2017-7244, CVE-2017-7245, CVE-2017-7246) as "not-affected", since the
32-bith character support wasn't enabled in wheezy (or jessie, for
that matter). I still spent some time trying to reproduce the issues,
which require a compiler with an AddressSanitizer, something that
was introduced in both Clang and GCC after Wheezy was released, which
makes reproducing this fairly complicated...
This allowed me to experiment more with Vagrant, however, and I have
provided the Debian cloud team with a 32-bit Vagrant box that was
merged in shortly after, although it doesn't show up yet in
the official list of Debian images.
Then I looked at the apparmor situation (CVE-2017-6507),
Debian bug #858768). That was one tricky bug as well, since it's not a
security issue in apparmor per se, but more an issue with things that
assume a certain behavior from apparmor. I have concluded that Wheezy
was not affected because there are no assumptions of proper isolation
there - which are provided only starting from LXC 1.0 - and Docker is
not in Wheezy. I also couldn't reproduce the issue on Jessie, but, as
it turns out, the issue was sysvinit-specific, which is why I couldn't
reproduce it under the default systemd configuration shipped with
Jessie.
I also looked at the various binutils security issues: as I reported on the mailing list, I didn't see anything serious
enough in there to warrant a a security release and followed the lead
of both the stable and Red Hat security teams by marking this
"no-dsa". I similiarly reviewed the mp3splt security issues (specifically CVE-2017-5666) and was fairly puzzled by that issue, which seems
to be triggered only the same address sanitization extensions than PCRE, although there was
some pretty wild interplay with debugging flags in there. All in all,
it seems we can't reproduce that issue in wheezy, but I do not feel
confident enough in the results to push that issue aside for now.
I finally uploaded the pending graphicsmagick issue (DLA-547-2), a regression
update to fix a crash that was introduced in the previous release
(DLA-547-1, mistakenly named DLA-574-1). Hopefully that release should clear up some of the
confusion and fix the regression.
I also released DLA-879-1 for the CVE-2017-6369 in
firebird2.5 which was an interesting experiment:
I couldn't reproduce the issue in a local VM. After following
the Ubuntu setup tutorial, as I wasn't too familiar with the
Firebird database until now (hint: the default username and password
is sysdba/masterkey), I ended up assuming we were vulnerable and
just backporting the patch after seeing the jessie folks push out a
release just in case.
I also looked at updating the ca-certificates package to
deal with the pending WoSign/Startcom
removal: I made an explicit list of the CAs that need to be removed
after reviewing the Mozilla list. I also sent a patch for an unrelated
issue where ca-certificates is writing to /usr/local (!!) in Debian bug #843722.
I have also done some "meta" work in starting a discussion about fixing the
missing DLA links in the tracker, as you will notice all of the
above links lead to nowhere. Thanks to pabs, there are now some
links but unfortunately there are about 500
DLAs missing from the website. We also discussed ways to Debian bug #859123,
something which is currently a manual process. This is now in the
hands of the excellent webmaster
team.
I have also filed a few missing security bugs (Debian bug #859135,
Debian bug #859136), partly because I wanted to help the security
team. But it turned out that I felt the script needed some
improvements, so I submitted a patch to improve the script so it is easier to
run.
Other projects
As usual, there's the usual mixed bags of chaos:
- converted the Charybdis IRC operator guide from SGML (yuck) to RST (PR)
- patches and discussions on
the
restic backup software review and
backup data generation program in
the hope of reducing duplication with the other two similar
projects (Obnam's genbackupdata and
Borg's
backupdata)
- atheme-services
security upload (still
need to do the same with charybdis
- neat cleanup of
the Python Cryptography
table of contents
(PR)
- basic maintenance on
the Linkchecker
project, including particularly a set
of
community guidelines which
I'd like to standardize as well
- raised a red flag on the security of the Weechat project by
reporting that most users are not aware that Weechat relays provide
arbitrary remote code execution to clients, upstream thinks users
are to blame, issue still opened
- git-annex
documentation:
semi-synchronized remotes and antipatterns
- tried to unblock the mess that TLS verification still is in Emacs
(Debian bug #816063)
More stuff on Github...
sysdba/masterkey), I ended up assuming we were vulnerable and
just backporting the patch after seeing the jessie folks push out a
release just in case.
I also looked at updating the ca-certificates package to
deal with the pending WoSign/Startcom
removal: I made an explicit list of the CAs that need to be removed
after reviewing the Mozilla list. I also sent a patch for an unrelated
issue where ca-certificates is writing to /usr/local (!!) in Debian bug #843722.
I have also done some "meta" work in starting a discussion about fixing the
missing DLA links in the tracker, as you will notice all of the
above links lead to nowhere. Thanks to pabs, there are now some
links but unfortunately there are about 500
DLAs missing from the website. We also discussed ways to Debian bug #859123,
something which is currently a manual process. This is now in the
hands of the excellent webmaster
team.
I have also filed a few missing security bugs (Debian bug #859135,
Debian bug #859136), partly because I wanted to help the security
team. But it turned out that I felt the script needed some
improvements, so I submitted a patch to improve the script so it is easier to
run.
About a year ago I bought a new workstation computer for myself at
home. It s a 
The other day I had to deal with an outage in one of our LDAP servers,
which is running the old Debian Wheezy (yeah, I know, we should update it).
We are running openldap, the slapd daemon. And after searching the log files,
the cause of the outage was obvious:
So, once again I had a box that had been installed with the kind-of-wrong
Debian architecture, in this case, powerpc (32 bit, bigendian), while I
wanted ppc64 (64 bit, bigendian). So, crossgrade time.
If you want to follow this, be aware that I use sysvinit. I doubt this can
be done this way with systemd installed, because systemd has a lot more
dependencies for PID 1, and there is also a dbus daemon involved that
cannot be upgraded without a reboot.
To make this a bit more complicated, ppc64 is an unofficial port, so it is
even less synchronized across architectures than sid normally is (I would
have used jessie, but there is no jessie for ppc64).
Step 1: Be Prepared
To work around the archive synchronisation issues, I installed pbuilder and
created 32 and 64 bit base.tgz archives:
Here is my monthly update covering what I have been doing in the free software world (
On 1st May 2006
Over the last few days I've been at the GNOME Developer Experience hackfest
in Brussels, looking into
My monthly report covers a large part of what I have been doing in the free software world. I write it for 
Sharing a scanner over the network using